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DECLARATION UNDER 37 CFR S 1.132 

I, Stanley Foster, hereby declare as follows. 

1 . I am a technical contributor at Hewlett-Packard Company, which is the assignee 
of the present patent application identified above (referred to herein as the "present patent 
application). 

2. In my capacity as a technical contributor, I work on designing, developing and 
deploying Microsoft Windows solutions, at least some of which integrate with Microsoft 
Exchange Server. 

3. I have been a software engineer for over 30 years. I am certified in Microsoft 
Windows programming including .Net and XML. During the last 10 years my work has focused 
primarily on developing and deploying software solutions involving Microsoft Windows and 
Microsoft Exchange. 
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4. Paragraphs 10 and 13 of this Declaration refer to Ben Goetter, Developing 
Applications for Microsoft® Exchange with C++, 14-15 (1996), which is attached hereto 
as Exhibit A. 

5. I have read the present patent application, including the pending claims. 

6. On page 16, lines 16-19, the present patent application discloses that the access 
module 120 manages sessions by creating XML structures for holding long variable names and 
references and by passing only simple references to the destination device. When the destination 
device needs particular data, the simple reference may be replaced on the server with the actual 
referenced data, which may be passed to the messaging/collaboration server. 

7. On page 18, lines 10-34, the present patent application discloses a 
sessionID_Inbox.xml file that contains "ID=" statements, which associate respective simple 
references (i.e., the ID type values "1", "2", "3", "4", and "5") with GUID (Globally Unique 
IDentifier) numbers that reference respective messages in an "Inbox" folder that is maintained by 
a Microsoft Exchange server on which the access module 120 is executing. 

8. Both before and since October 6, 2000, various versions of the Microsoft 
Exchange Server software have used unique, global pseudo-random 128-bit GUID numbers to 
identify items maintained in messaging/collaboration folders (e.g., contacts, calendar, e-mail and 
tasks folders). 

9. Both before and since October 6, 2000, application programs routinely have 
retrieved items from Microsoft Exchange Server folders by sending the server the GUIDs for the 
folders and the items to be retrieved. 

10. For a brief introduction to the use of GUIDs by Microsoft Exchange Server 
applications, see for example, Exhibit A, Goetter, supra paragraph 4, at 14, which explains 
that: 



For a client to ask a component object for an interface, the client 
needs to have a name for that interface: a token that the client and 
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component agree represents the interface and that neither can 
mistake for any other interface. Recall that any change to an 
interface results in a new interface distinct from the old one. 

Every named object in the universe of COM has as its true name a 
Globally Unique Identifier, or GUID. A GUID is a 128-bit integer, 
spanning a theoretical range from 0 through (2 128 )-1, or 
approximately 3.4 x 10 . 

11. The number following the folder label "Inbox" and contained within quotes in 
sessionID_Inbox.xml file on page 18, lines 1 1-14, of the present patent application is the GUID 
for the "Inbox" folder that is maintained by the Microsoft Exchange server on which the access 
module 120 is executing. 

12. Similarly, the 128-bit numbers following the brackets ">" in the ID="[number]" 
statements in the sessionID_Inbox.xml file on page 18, lines 10-34 of the present patent 
application are the GUID reference numbers that are used by the Microsoft Exchange server to 
identify messages in the "Inbox" folder. 

13. For an example of a conventional way in which a GUID may be presented, see for 
example, Exhibit A, Goetter, supra paragraph 4, at 15, which explains that: 



By convention, we write a GUID value as a series of hexadecimal 
digits, separated with hyphens that demarcate its internal structure 
and delimited with braces, {00000000-0000-OOOOCOOO- 
000000000046}, with the most volatile time elements to the left 
and the machine identifier to the right. 



14. The "ID=" statements in the sessionID_Inbox.xml file tell an XML parser running 
on the Microsoft Exchange server to replace the respective simple references (i.e., the ID type 
values "1", "2", "3", "4", and "5") with the associated GUID reference numbers. Each of the 
"ID=" statements is an indirection to map from a respective ID type value provided by a client to 
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an associated GUID reference number that is maintained in some session context by the server in 
the sessionTO_Inbox.xml file, where "ID" is a tag that is used to pass the simple reference that 
replaces the associated GUID reference number. 

15. When applied to the exemplary sessionTO_Inbox.xml file on page 18, lines 10-34 
of the present patent application, the disclosure on page 16, lines 16-19, of the present patent 
application means that the access module 120 creates the sessionIDJnbox.xml file and passes 
the simple references (Le., the ID type values "1", "2", "3", "4", and "5") to the destination 
device without passing the actual referenced data (Le., the message items in the "Inbox" folder 
that are identified by the GUID reference numbers associated with ID type values). 

16. I declare that all statements made herein of my own knowledge are true and that 
all statements made on declaration and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code, and that such willful felse statements may jeopardize the validity of the application or any 
patent issuing thereon. 



Respectfully submitted, 
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EXHIBIT A 



PUBLISHED BY 
Microsoft Press 

A Division of Microsoft Corporation 

Or*e Microsoft Way 

Redmond, Washington 98052-6399 

Copyright & 1996 by Ben Goetter 

All rights reserved. No part of the concepts of shis book may be reproduced or 
transmitted m any form or by any means without the written permission of the publisher. 

Library of Congress Catalogiing-in-Publicatiosi Data 
Xxocuez, Ben, 1964- 

Bevelopmg Applications for Microsoft Exchange -with C*+ /Ben Goetter. 
p. cm. 

Includes index. 

ISBfS* 1-37251-500-3 

1. Microsoft Exchange. 2. Client/server computing. 3- 
(Computer program language) L Title, 
QA76.:9.C55G63 1996 

Q057 , ll-dc20 96-2S6X9 

CiP 

Primed and bound in eke United States of America. 
123 456789 ML2ML 109876 

Distributed to the book fcrade in Canada by Macmtllan of Canada, a division of Canada 
Publishing Corporation. 

A CfF catalogue record far this book is available from the British library. 

Microsoft Press books are available through booksellers and distributors worldwide. For farther 
information abou£ internasKHtai editions* cos&arx your local Microsoft Corporation office. Or 
contact Microsoft Press limerna&onat directly at fax C2C6) 936-7329. 

Apple and Macintosh are registered trademarks of Apple Computer, inc. CompuServe is a 
registered trademark oi CompuServe, Inc. Alptira AXP and DEC axe trademarks of 'Digital 
Equipment Corporation. Intel is a registered trademark of Intel Corporation. Power PC is s 
trademark of international Business Machines Corporation. Microsoft, M5-DOS, Visual Basic, 
Visual C+*. Win32, Windows, and Windows NT are registered trademarks and AcsrveX and 
BackOffice are trademarks of Microsoft Corporation- Netware and Novell are registered 
trademarks of Noveli* lac. Other product and company names mentioned .herein may be 
the trademarks of their respective owners. 

Ac^uisitio(ns JBditoTr Casey D. Doyle 

Project Edifcws: Patricia 3SL Wagner; Caroline Pacbaud 

XectoJcal Editor^ Christina Artagnast 
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^K^p\^JPersis^tom^y^\i^ the interface completely subsumes another inter- 
face -Cm this example, IPersisiy. This is very rare, witih one important exception: 
every interface includes JUnkrmum in such a manner that every injfcerfaoe effec- 
tively as if it had i^eritediW^c^^ In cdier words, erery inter- 
face delivers the mediantsni* by which a clieni can. request another interface from 
the component. 

Oi?|ecf Naming 

For a client to ask a component obfect for an interface, the client needs to have 
a name for that interface: a token that the client and component agree represents 
the interface and ■ that neither can mistake for any other interface. Recall that any 
change to an Interface results in a new interface distinct from the old one. 

Every named obfect in the universe of COM has as its true name a Globally 
Unique Identifier, or GUID. A GUID is a 128-b3t integer, spanning a theoretical 
range from 0 through (2 l2S ) -1 , or approximately 3.4 x 10 s3 . 

As die name indicates, each. GOID value is "globally unique": it exists to uniquely 
identify one object class in the universe. A GUID musl be unique to be -valid; 
once one has been assigned to name something, it must never be reassigned 
elsewhere/ lest two patties hold two different definitions of the same name. 
Imagine; for example, what might happen if everybody developed a fondness 
for the GOID value 1 (certainly much easier to remember and type than a chain 
of 32 hexadecimal digits or 38 decimal digits). Or picture the confusion that 
would arise in interface negotiations: a man staggers into a room, sees a. figure 
in a white coat, and gasps, "Are you a doctor?* To which rhe helpful diese] 
mechanic responds, "Why, yes I am. How may I help you?" Bad news, unless 
the sick man runs SAB SOW for blood! 

Developers allocate GUIDs with an algorithm designed to prevent such colli- 
sions. The internal structure of a GOID includes 48 bits of macliine-speclfic 
unique seed, such as an Ethernet or a Token-Ring tserwoik address (if available), 
representing the system that allocated the GUID. together with 64 bits of time 
in Universal Time Coorfinates (UTO format, representing the time at which the 



Fortunately, w&te 2 ,3S possible GUID values, there's oo jioed co allocate thein parsimoniously 
This ran&e could aoooEtiaiDd2!£r assigning a GU10 to every hair on every Ihead on evesy person 
ins tire world. BiEthernaoee, in asi *cbo of H&rtoft Hems a Who, trvery hair on our world could 
actually acxXHJiniodme an enHre tiay woefd* equally papukxis and hirsute as oar own, acid yoxx*d 
ssiU We enough CtHDs to assign each :ilny hair its own value. Indeed* you &cmf<i repeas this 
alikxasiaa over 300 miliars iEart^sixed p^nets, each w&h lialry inhalants carrying ar 2 inhabited 
worfd on each hair, before you'd extiauass ihe space. Aren't orders of magriivudc fua? 
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system allocated it This allows each of 2,8 x hosts (the rang£ of tihe xoaehli^e- 
specific identifier) to allocate 10 S 0£X*,0Q0 GUIDs per ^eond for the next 3000 
years (the range of 64-foit UTCX 

When a GUID names an. mierfaee, the GUID is an toerfaoe ID % at IID. GUIBs 
name more diao fust interfaces, however; everywhere a unique name is neces- 
sary, a GUID appears, posssbly under a different label They can name class 
objects, ki which case the GUIDs trice the name OLSIBs, or they caa name remote 
procedure call CRPC} proxies, in which case they travel as UUlDs^ 

By convention, we write a COED value as a series of hexadecimal digits, sepa- 
rated with hyphens thai demarcate its internal structure and deltrnited with 
traces. ^90^06^ the most volatile time 

element lo the left and die machine identifier to the right. Because mosi fleshy, 
caitx>arba5ed people don't work naturally with i28-bit numbers as names, this 
book uses symbolic constants or shorthand instead of literal GUID values. Hie 
quantify listed above, for instance, appears only once m this book and in the 
API documentation, even though its the most commonly used interface name 
in die systems lUnimoum. Instead of using the literal GUID value, the code refers 
to the symbol IK>JUnknomn % while the documents naone it as lUnknoum. 

Object Ulespcsii 

Component objects are bodies— logical "obfects* in the objed-orient€d program- 
ming sense— that articulate interfaces to their daents. These objects have a life 
span: they come into existence at a clienfs demand, fulfil whMev-er requests 
are made of them, and fanally vanish when they are no longer needed. 

The body of code that implements a particular component obpear is called the 
con$x*nen£ class. In the model mosc common to ActiveX, a client loads the class 
it needs, passing the system COM library a CL5ID— die GUID naming a particular 
etess—and getting in remm a. class object. A class object (frequently called a class 
factory to reduce overwork of the already grievously abused o-wocd) is itself 
just a form of component object, one that exports the imerface laassFactory; 
the client; interacts with the class factory's offered lOassFaetory interface to 
request instances of the component obfeot implemented by the class, as shown 
in Figure 1-6 on the following page. 



5. Tfifs ssihe same tRIID t§iai rise Open. Safivwe Faimdariois (OSF> Distributed Cam^utteg Ha- 
vir-asuncsit (tPCE) ReroaOe Proo£»dure Oil! xt&ch&r3sai uses. 
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